Chrome has shipped the clipboard-read permission, so this would be a breaking change for us.

@dway123 do we have any data we could share about the magnitude of the breakage?

Sure. The suggested removal of clipboard-read here implies requiring user activation to gate Clipboard read. Therefore, this should break any site that currently doesn't require user activation to read the clipboard.

While we don't know the exact magnitude of the breakage (we don't currently have metrics on clipboard read use without user activation), we do know that:

• .03% of pageloads currently use clipboard.read(), and .22% of pageloads currently use clipboard.readText(). The subset of these sites that doesn't do so requiring user activation would be broken by this change.
• As of September 2020, 11,088 unique sites made use of the Async Clipboard API, according to the HTTP Archive. This number may be higher now, but also includes sites using clipboard write but not clipboard read, or clipboard read, but with user activation, so may represent more than the complete list of affected sites.
• Remote desktop applications, including cendio.com, as well as Chrome Remote Desktop, would be broken by this change, as this would disallow them to propagate clipboard updates.

Sure. The suggested removal of clipboard-read here implies requiring user activation to gate Clipboard read. Therefore, this should break any site that currently doesn't require user activation to read the clipboard.

Aren't those sites also broken in Firefox & Safari? Or are you more concerned about Chrome only content?

Aren't those sites also broken in Firefox & Safari? Or are you more concerned about Chrome only content?

I suspect but have not verified these sites are also broken in Firefox and Safari, if they require user gesture for all Clipboard reads. I only discussed Chrome content because the question was regarding breakage in Chrome, and I only had public use information for Chrome, like chromestatus feature use data. Please share information about breakage in Firefox & Safari, if possible, to provide more color for this conversation. Sorry, I'm not well acquainted with available public data for Firefox & Safari.

Please share information about breakage in Firefox & Safari, if possible, to provide more color for this conversation.

I don't think Firefox typically collects this kind of information (though some from Mozilla can correct me). They would need to check specific sites to see if they are breaking. However, likelihood is that they are not broken if the read is happening along with a user gesture... hopefully sites have figured that out already and at mitigating breakage by calling the API as a result of user activation.

I can confirm that Mozilla doesn't have a use counter for navigator.clipboard.

So, just chiming in a chair here. The appropriate course of action would be to merge this to match implementations. Then, as a followup, if folks from Google would still like to pursue this option, it might be worth sending a PR reverting the changes made in this PR.

Aren't those sites also broken in Firefox & Safari? Or are you more concerned about Chrome only content?

I suspect but have not verified these sites are also broken in Firefox and Safari, if they require user gesture for all Clipboard reads. I only discussed Chrome content because the question was regarding breakage in Chrome, and I only had public use information for Chrome, like chromestatus feature use data. Please share information about breakage in Firefox & Safari, if possible, to provide more color for this conversation. Sorry, I'm not well acquainted with available public data for Firefox & Safari.

Safari does not collect such data either. Given Safari always requires user gesture to paste, it's pretty safe to assume such websites are broken in Safari. If those websites are broken in Safari, on the other hand, it means the website has some Chrome/Chromium specific behavior. Even in such a scenario, this will likely remain Chrome/Chromium only permissions so the two-implementation requirement means that this permission should not be added back to the spec.

Ok, I'm going to go ahead and merge this, as the two engine requirement hasn't been met for this feature.